Too often these days I am amazed at the lack of forethought that goes into harnessing the built in functionality of a platform. I am talking specifically about the code base here. I'm thinking from high level objects, down to single small functions.

Take a moment to step back and examine your code use. Was there a reason that you picked that language? I'm guessing that there would have been some sort of analysis of the technologies on offer, and you picked the one you currently have.

All too often people shoot off in random directions of development without really examining the functionality that a platform already provides.

My main field of development experience is coldFusion, so I'll use this as my example. An all too common example of this is the 'application.cfm', or 'application.cfc' file. This file is a directory level extender. IE any files in the same directory, or indeed sub directories will inherit properties set in it. This makes it ideal for things like user access, and session management, and general data persistence. In almost every custom built framework I have come across someone has decided that they would rather handle this is a different fashion. Now I'm not against writing custom code, far from it, but I think it is very important to know what your code base can already do - here's why:

• Why write functionality again, when it is already there?
• Its a standard function of the code base. Its generally going to be more efficient than anything your writing 'custom'
• Depending on wether your open source or not, it will have generally been tested by a huge variety of developers, and software companies. Has your custom function?
• Bringing in new staff, and contractors and introducing them to custom functionality is time consuming. Chances are they already know, or have at least heard of most of the in built platform functionality.

There are obviously exceptions to the rule, sometimes the intrinsic code simply does not do exactly what you want it to. So before you race off and write a huge error handler, or string replacement method, take a look around, you might find that it is in fact already under the hood.

Often a project's success is measured by whether or not it was successfully delivered, and if the release was relatively painless.

People see the finish line of a project and start making compromises or try to expedite the project delivery, as they can see that the end is in sight. It is this race for the finish that can compromise a projects completion.

In my experience one of the most important parts of the project life cycle is the Post Implementation Review. It is also the most often overlooked part of the project for the reasons mentioned above, or indeed omitted altogether if a company isn't used to accurately measuring the success of a project in more in-depth terms than 'did it go live successfully' (Which is the poorest measure of success).

Essentially this process answers the question "Did we manage to deliver what we set out to do". It tries to accurately gauge whether or not the business case for a project has been met, and if not, where the shortfalls are.

The Post Implementation Review is an ideal opportunity to validate several aspects of the project, and feed that data back into your PM process to the benefit of future projects.

It can be as basic as a simple document asking several basic questions, such as:

1. What of the initial business objectives did we meet?
2. What did we learn from this project?
3. What was different than expected?
4. Were there an unexpected issue during the project.
5. Would we manage any elements of the project differently if repeated?
6. How do our initial estimates relate to our actual delivery timescales?
7. How did we manage the unforeseen?

Several important sets of data should be included in it though, for example if you have any sort of estimation and/or time tracking process this is the ideal place to correlate that data with the actual project time frames as you now know exactly how long it took to deliver the project. This is an important step in refining your estimation analysis, and can greatly improve the accuracy of future projects. After all what is the point of time tracking a project, if you don't actually match up the estimated figures to the actual figures.

This is also a good opportunity to examine the release management process implemented, and assess whether all potential risks to the project and the existing infrastructure were accurately foreseen. This is easily answered by a brief comparison against any release documentation you may have, as you should quickly be able to see if any risks highlighted in that were minimized.

It is also a very good opportunity to explain and release shortfalls to interested shareholders. Often if a project misses a deadline, or is badly implemented it is never actually explained to the business why. They simply assume that there was a problem. By explaining here you are keeping them informed, and on-side. By explaining that here you are also documenting it for future projects.

If you did not see a risk that affected your projects release this time, then surely it needs documenting and a greater level of understanding about it reached for next time. In this way you have a more complete picture of your overall architecture.

Just because a project has been released it does not mean you cannot learn anything else from it, often it is entirely the opposite. Haste to proceed onto the next project can often cause this step to be skipped entirely, but once you have tried it a few times its value will become more than apparent, both as a project analysis tool, and a vehicle for shaping real process change inside the business.

I will include a template at the bottom of this article that I have found useful in the past. Hopefully this brief explanation will give you the incentive to look at introducing a Post Implementation Review into your projects.

An example Post Implementation Review document.

This article deals with creating a SQL stored procedure for Updating a record.

In each of these stored procedure templates I am declaring a variety of documentation parameters in the header.

I've found these handy in the past when you are working in a team environment, or when you go back to a procedure at a later date. Its much easier to read a simple description in the header, than trawl through the SQL code looking for what it is doing.

So, this declares the procedure name, any parameters and return codes, and also details what it does, and who made it.

In a modified version of this I also hold the SVN revision number here.

The next block of code performs a select on the sysObjects table (part of the Master database). It is checking for the existence of itself. If it finds itself, it will drop the procedure. Note that throughout all of these scripts we are telling the user at each stage what is going on, by printing useful english output back to the screen.

By now we have identified whether or not the procedure previously existed, and if it did, we have dropped it, so we know that we are all good to go. So to create our Update procedure, we print out a message to the user, then using the "CREATE PROCEDURE" command we create our procedure.

At this point you substitute the "@field" value with your field name, and the [datatype] and (datasize) with the correct values. Just list your fields one after another, seperating with a comma. As this is creating an Update stored procedure I will list any of the values to update in the query here.

After that we create the SQL code, as per usual. We have an Update statement, using the variables declared above in the SQL variable declaration (@var). Just write out your update like you normally would here. Then we check for any errors, and return a success message if it all worked ok!

By using a script like this I've found that its really simple to have a repeatable standard process that is easy to implement across a team of developers, ensuring you get the same results, no matter who writes the query. It is also very useful if you have a seperate implementation team, as these scripts are re-runnable, they clear up after themselves.

Download the full template here.